4W - 실리움 라우팅 모드 실습 - native, vxlan, geneve

#published #kubernetes/cluster/cni/cilium #study/cloudnet/cilium1 #os/kernel/ebpf #protocol/vxlan #protocol/geneve #network/overlay

개요

이번 주부터는 실리움에서 제공하는 다양한 기능을 확장시켜 바라보는 시간을 가진다.
구체적으로 다음의 내용을 다룬다.

이번 주차에서는 라우팅 모드 중 VXLAN, GENEVE를 활용한 캡슐화 방식을 조금 더 깊게 파볼 것이다.
실습에 있어서 깊게 파고들 필요는 없지만 조금이라도 각 프로토콜의 특징에 대해서도 알아보자.
이 방식의 장점은 다음과 같다.

VXLAN

VXLAN(Virtual eXtensible Local Area Network)은 VLAN(Virtual Local Area Network)의 한계를 극복하기 위해 등장한 기술이다.[1]
전반적으로는 L2 이더넷 프레임을 L3 UDP 패킷으로 캡슐화(Encapsulation)하여 기존 IP 네트워크 위에서 터널링하는 방식을 이용한다.
L3를 활용해 L2 대역을 넓히는 기술인 것이다.

배경

먼저 선조격인 VLAN은 말 그대로 가상의 LAN을 만드는 기술로 하나의 스위치로 여러 브로드캐스트 도메인을 나누기 위해 등장했다.
VLAN은 장비를 효율적으로 사용하면서 각 회선의 간 경합, 보안 영역을 분리할 수 있는 기술로 지금도 실무 환경에서는 절찬리에 사용되고 있다.
그러나 기술이 발전하면서 점차 VLAN으로 커버하기 어려운 요건이 발생하기 시작했다.

두번째 문제에서 VLAN은 명확하게 프로토콜 차원에서 한계를 지닌다.
VLAN은 본디 L2 이더넷 프레임에 12bit로 VLAN ID를 부여해서 네트워크 영역을 나눌 수 있게 표시를 해둔다.
이는 곧 VLAN이 분리시킬 수 있는 네트워크 영역은 최대 4094개 정도라는 것인데, 현대 환경에서는 이 정도의 범위도 부족할 수 있다.
가상 환경이 대두되며 가상의 호스트를 자유롭게 만들 수 있게 됐고, 클라우드 컴퓨팅까지 접목되니 이제는 네트워크 영역 만 개 단위는 우습게 처리할 수 있어야 하는 상황이 되어버린 것이다.
L3 레벨에서 멀티 테넌시를 최대한 구축하는 것도 가능하나, L3에서는 비즈니스 도메인과 결합성이 높아지기도 하고 다른 서비스와 프로토콜과의 연관도가 높아서 이것도 만족스러운 선택지가 아니다.

이러한 수요 아래 VLAN을 L3 차원에서 확장시키기 위한 기술로 VXLAN이 나온 것이다.

구조

구조는 그다지 복잡하지 않다.

VXLAN은 위에서 말했듯이 L2 프레임을 통째로 한번 감싸서 L3 이상의 영역으로 보내는 프로토콜이다.
그래서 외부 프레임 안에 내부 프레임이 따로 들어가는 구조를 가지고 있고, 이때 내부 프레임을 식별하는데 사용하기 위한 VXLAN 헤더 8바이트가 들어간다.

여기에서 알아둬야 할 용어 두 가지만 먼저 짚어본다.

VXLAN 헤더는 위처럼 VNI 24비트가 들어가며 총 64 비트(8바이트)로 구성된다.
나머지는 사실 전부 Reserved 상태로, 언젠가 사용될 수 있도록 0으로만 채워져 있다(1이어도 무시된다).
딱 한가지, 맨 앞 8비트를 VXLAN 플래그라 하며 중간 5번째 비트는 1로 채우는데, 이는 VXLAN 패킷이 정상적임을 나타내는 신호이다.

보통 이더넷 프레임은 802.3 형식에 따라 MTU(Maximum Transmission Unit, 전송 가능한 최대 데이터 크기)가 최대 1500 바이트로 한정된다.[2]

그런데 VXLAN을 사용하게 되면 캡슐화를 통해 들어가는 헤더들 덕에 최대 1450 바이트까지만 데이터를 전송할 수 있게 된다.
그 이유는 아래 그림의 헤더를 보면 알 수 있다.
image.png
맨 아래 윗 계층의 페이로드가 담기기 전까지, 위의 여러 헤더들이 자리를 차지하게 된다.

이러한 방식으로 인해 50 바이트 가량을 전송 데이터로 활용할 수 없다는 점을 유의해야 한다.
이더넷 프레임 체크섬으로 마지막에 붙는 FCS(Frame Check Seqeunce)는 내부 이더넷 프레임에는 붙지 않아 여기에서 활용 가능한 MTU가 더 줄지는 않는다.

Geneve

Geneve(Generic Network Virtualization Encapsulation)는 다양한 오버레이 프로토콜들의 장점을 결합하고 확장성 있게 설계된 최신 프로토콜이다.[3]
크게는 VXLAN, NVGRE(Network Virtualization using Generic Routing Encapsulation)을 결합했다고 한다.

방식 자체는 VXLAN과 다를 게 1도 없으니 자세히 설명하지 않겠다.
Geneve 헤더는 가변적인 크기를 가지는데, 고정적인 필드 부분도 VXLAN에 비해 헤더를 야무지게 쓴다.
image.png
Variable-Length Options 부분이 가변적으로 추가될 수 있는 필드이다.

가변 길이 필드의 옵션은 아래와 같은 구조로 이뤄진다.
image.png
각 옵션은 Type과 Length, 그 이후에 값이 붙는다고 하여 TLV 형식이라고 부른다.

실습 환경 구성

이전 글에서 네이티브 라우팅 모드로 세팅할 때 각 노드의 라우팅 테이블에 어떻게 세팅되는지 알아보았다.
이번에는 네이티브 라우팅 모드에서 발생할 수 있는 문제를 짚어보고, 캡슐 모드를 실습해볼 것이다.

먼저 전체 환경은 이렇게 구성된다.
image.png
(가시다님 자료)
클러스터를 구성하되, 한 노드는 다른 대역에 위치한 상황이다.
그래서 두 대역의 통신이 가능하도록 하는 라우터가 배치되어 있다.

자세한 설정 파일은 레포를 참고하도록 한다.

vagrant up
kaf check.yaml

배치를 하고 192.168.10.0 대역에서 확인해보면 일단 라우팅 경로 자체는 나와있다.
image.png
라우터 역할을 수행하는 vm으로 20 대역의 트래픽을 보낼 것이고, 라우터는 정상적으로 트래픽을 처리해줄 것이다.

기타 정보도 확인해보자.
먼저 의도한 대로 모든 노드에 파드가 골고루 배치됐고, 준비 상태이다.

kubectl get ciliumendpoints # IP 확인

image.png

kubectl exec -n kube-system ds/cilium -- cilium-dbg ip list
kubectl exec -n kube-system ds/cilium -- cilium-dbg endpoint list
kubectl exec -n kube-system ds/cilium -- cilium-dbg bpf nat list

export SVC=$(kubectl get svc webpod -ojsonpath='{.spec.clusterIP}')
kubectl exec -n kube-system ds/cilium -- cilium-dbg service list | grep $SVC -A5
kubectl exec -n kube-system ds/cilium -- cilium-dbg bpf lb list | grep $SVC


kubectl exec -n kube-system ds/cilium -- cilium-dbg map list
kubectl exec -n kube-system ds/cilium -- cilium-dbg map get cilium_lb4_services_v2
kubectl exec -n kube-system ds/cilium -- cilium-dbg map get cilium_lb4_services_v2 | grep $SVC

실습에 사용할 서비스는 제대로 모든 대상 파드를 가리키고 있고, 이 정보는 bpf에도 저장돼있다.
image.png
image.png

kubectl exec -n kube-system ds/cilium -- cilium-dbg map get cilium_lb4_backends_v3
kubectl exec -n kube-system ds/cilium -- cilium-dbg map get cilium_lb4_reverse_nat
kubectl exec -n kube-system ds/cilium -- cilium-dbg map get cilium_ipcache_v2

네이티브 라우팅의 한계

첫 세팅은 네이티브 라우팅 모드로 진행한다.
클러스터 구성 시 다른 대역의 노드 조인 자체는 라우터가 라우팅을 책임져주기 때문에 문제 없이 가능했다.
그러나 파드 대역의 라우팅은 현재로서는 자연스럽게 이뤄지지 않는다.

kubectl exec -it curl-pod -- sh -c 'while true; do curl -s --connect-timeout 1 webpod | grep Hostname; echo "---" ; sleep 1; done'

image.png
서비스의 백엔드 3파드 중 두 파드에 대한 통신은 이뤄지지만 나머지 하나가 말썽이다.

아예 조금 더 명확하게 파악해보자.

export WEBPOD=$(kubectl get pod -l app=webpod --field-selector spec.nodeName=k8s-w0 -o jsonpath='{.items[0].status.podIP}')
kubectl exec -it curl-pod -- ping -c 2 -w 5 -W 5 $WEBPOD

# 신규 터미널 [router]
vagrant ssh router -c "sudo tcpdump -i any icmp -nn"

image.png
이 상황의 문제는 당연하다.
네이티브 라우팅 모드로 라우팅 테이블에 어떤 파드 대역은 어디로 가야하는지 지정은 해줄 수 있지만, 정작 이를 받은 라우터가 파드 IP를 이해하고 적절하게 라우팅 해주지 못하는 상황인 것이다.
결국 패킷은 디폴트 게이트웨이로 빠져버리고 있다.
해결 방법은 매우 간단하게 라우터에 파드 IP 대역에 대한 라우팅 규칙을 설정해주기만 하면 된다.

# 실패한 방법
CIDR=$(k get ciliumnode k8s-w0 -ojsonpath='{.spec.ipam.podCIDRs[0]}')

vagrant ssh router -c "sudo ip r del default dev eth0 "
vagrant ssh router -c "sudo ip r add $CIDR dev eth2 "
vagrant ssh router -c "sudo ip r add default dev eth2 "

#vagrant ssh router -c "sudo ip r del $CIDR dev eth2 "
vagrant ssh router -c "sudo ip r del default dev eth2 "

노드가 적고 IP 변경이 없을 것이란 확신이 있다면 이러한 방식이 문제될 것은 없다.
스태틱 라우팅은 실제로도 작은 규모의 네트워크에서는 잘 쓰이는 방식이다.
다만 결국 유동적으로 확장과 축소가 이뤄지는 환경에서는 동적 라우팅 방식을 활용하는 게 훨씬 현실적이다.
다음 주차에 배울 BGP 기능은 이를 훌륭하게 보완해줄 수 있다.

물론 네이티브 라우팅을 쓰지 않고 캡슐 모드를 쓰는 것도 방법이다!
이제부터는 캡슐 모드를 사용해보자.

VXLAN 모드 실습

첫번째 방법인 vxlan 방식을 먼저 사용해보자.
먼저 위해서는 커널의 vxlan 모듈을 활성화해야 한다.

# vm 접속
grep -E 'CONFIG_VXLAN=y|CONFIG_VXLAN=m|CONFIG_GENEVE=y|CONFIG_GENEVE=m|CONFIG_FIB_RULES=y' /boot/config-$(uname -r)

image.png
각 의미는 다음과 같다.

이제 모든 노드의 모듈을 로드한다.

for i in ctr w1 w0 ; do echo ">> node : k8s-$i <<"; vagrant ssh k8s-$i -c 'sudo modprobe vxlan' ; echo; done

#  커널 로드
for i in ctr w1 w0 ; do echo ">> node : k8s-$i <<"; vagrant ssh k8s-$i -c "lsmod | grep -E 'vxlan|geneve'" ; echo; done

image.png

다음으로 실리움을 업데이트해준다.

helm upgrade cilium cilium/cilium --namespace kube-system --version 1.18.0 --reuse-values \
  --set routingMode=tunnel --set tunnelProtocol=vxlan \
  --set autoDirectNodeRoutes=false --set installNoConntrackIptablesRules=false
  
kubectl rollout restart -n kube-system ds/cilium
cilium features status
cilium config view

image.png
image.png
이 부분은 제대로 확인해보지 않았는데, vtep을 명확하게 지정하는 설정도 가능한가 보다.

통신에 사용될 새로운 네트워크 인터페이스가 생성됐다.

for i in ctr w1 w0 ; do echo ">> node : k8s-$i <<"; vagrant ssh k8s-$i -c 'ip -c r' ; echo; done
# cilium_vxlan 확인
for i in ctr w1 w0 ; do echo ">> node : k8s-$i <<"; vagrant ssh k8s-$i -c 'ip -c a show dev cilium_vxlan' ; echo; done

image.png

이제는 실제 통신이 가능해진다!

kubectl exec -it curl-pod -- sh -c 'while true; do curl -s --connect-timeout 1 webpod | grep Hostname; echo "---" ; sleep 1; done'

image.png
ping 통신도 제대로 되는지 확인해보자.

export WEBPOD=$(kubectl get pod -l app=webpod --field-selector spec.nodeName=k8s-w0 -o jsonpath='{.items[0].status.podIP}')
kubectl exec -it curl-pod -- ping -c 2 -w 1 -W 1 $WEBPOD
# 신규 터미널 [router]
vagrant ssh router -c "sudo tcpdump -i any udp port 8472 -nn"

image.png
vxlan에서 사용하는 udp 8472 포트를 이용해 모니터링한 것에 유의하자.
실제 패킷에 대한 내용물을 해석해서 ping이 제대로 이뤄지는 것까지도 확인된다.
tcpdump 이 정도하는 친구였나 ㄷㄷ

패킷을 조금 더 제대로 확인해보자.
실리움에서 vxlan 기본 포트는 8472로, IANA에서 지정한 4789와 달라 이를 반영하여 termshark가 파싱이 가능하도록 설정을 넣어주어야 한다.

kubectl exec -it curl-pod -- sh -c 'while true; do curl -s --connect-timeout 1 webpod | grep Hostname; echo "---" ; sleep 1; done'
vagrant ssh router -c "sudo tcpdump -i any udp port 8472 -w /tmp/vxlan.pcap"
vagrant ssh router -c "sudo termshark -r /tmp/vxlan.pcap -d udp.port==8472,vxlan"

image.png
http로 필터링하여 관찰하면 실제 패킷 구조에 대한 분석이 표시된다.
보다시피 중간에 VXLAN이 걸리고 다시 이더넷 프레임이 나오는 것을 볼 수 있다.
image.png
VNI는 42052를 받았는데, 이건 트래픽을 보내는 측의 신원이기도 하다.
image.png

마지막으로 허블로 관측해본다.

hubble observe -f  --pod curl-pod

image.png
요청하는 쪽에서의 트래픽을 to-overlay라고 표시되는 것이 보인다.

캡슐화를 하는 프로토콜은 필연적으로 데이터 패킷 크기가 줄어들 수밖에 없다.
이는 IEEE 802.3에서 지정한 이더넷 페이로드 MTU 1500을 온전히 사용할 수 없음을 나타낸다.

# -M do : Don't Fragment (DF) 플래그를 설정하여 조각화 방지 
# -s 1472 : 페이로드(payload) 크기, 즉 ICMP 데이터 크기
kubectl exec -it curl-pod -- ping -M do -s 1500 $WEBPOD

image.png
1500 크기로 날리자 IP 헤더, ICMP 헤더를 포함해서 28 바이트가 추가되어 패킷이 날아갔다.
그리고 이것은 조각화를 하지 않는 이상 한 프레임에 담을 수 없기에 요청이 날아가기 전에 에러가 반환된다.
위에서 VXLAN으로 인해 손해보는 패킷의 크기가 50바이트라 했다.
그런데 막상 해보면 1450 크기를 지정해서 날려도 통신이 불가능하다.
이는 ICMP 자체가 가지는 헤더 값까지 고려해야 하기 때문이다.[4]
image.png
이 상태에서 VXLAN은 외부 IP + VXLAN + 내부 이더넷하여 50 바이트를 추가로 소모하는 거라, 결과적으로 내부 IP + ICMP 헤더인 28 바이트까지 제외해 패킷 크기를 설정해야 제대로 통신할 수 있다.
image.png

GENEVE 모드 실습

다음으로 크게 다를 건 없지만 geneve로도 실습을 해본다.

for i in ctr w1 w0 ; do echo ">> node : k8s-$i <<"; vagrant ssh k8s-$i -c 'sudo modprobe geneve' ; echo; done
for i in ctr w1 w0 ; do echo ">> node : k8s-$i <<"; vagrant ssh k8s-$i -c "lsmod | grep  geneve" ; echo; done

image.png

helm upgrade cilium cilium/cilium --namespace kube-system --version 1.18.0 --reuse-values \
  --set routingMode=tunnel --set tunnelProtocol=geneve \
  --set autoDirectNodeRoutes=false --set installNoConntrackIptablesRules=false
  
kubectl rollout restart -n kube-system ds/cilium
cilium config view

image.png

이번에는 geneve용 인터페이스가 생성된 것을 확인할 수 있다.

for i in ctr w1 w0 ; do echo ">> node : k8s-$i <<"; vagrant ssh k8s-$i -c 'ip -c a show dev cilium_geneve' ; echo; done

image.png

통신은 동일하게 가능하다.

kubectl exec -it curl-pod -- sh -c 'while true; do curl -s --connect-timeout 1 webpod | grep Hostname; echo "---" ; sleep 1; done'

geneve는 6081 udp 포트를 사용한다.

export WEBPOD=$(kubectl get pod -l app=webpod --field-selector spec.nodeName=k8s-w0 -o jsonpath='{.items[0].status.podIP}')
kubectl exec -it curl-pod -- ping -c 2 -w 1 -W 1 $WEBPOD
# 신규 터미널 [router]
vagrant ssh router -c "sudo tcpdump -i any udp port 6081 -nn"

image.png
vxlan과 달리 이번에는 내부 내용물을 보여주진 않는다.

이번에도 패킷을 뜯어본다.

kubectl exec -it curl-pod -- sh -c 'while true; do curl -s --connect-timeout 1 webpod | grep Hostname; echo "---" ; sleep 1; done'
vagrant ssh router -c "sudo tcpdump -i any udp port 6081 -w /tmp/geneve.pcap"
vagrant ssh router -c "sudo termshark -r /tmp/geneve.pcap -d udp.port==6081,geneve"

image.png
현재 geneve 버전이 0으로 통신이 되고 있으며 플래그엔 아무런 값이 들어가 있지 않다.
Opt Len은 0으로 추가 옵션 필드가 들어가진 않았으니, 기본 필드 길이인 8바이트만이 사용됐을 것이다.
image.png
VNI는 항상 보내는 측의 신원으로 고정되는 모양이다.
캡슐 모드에서는 VNI 만으로도 트래픽을 어디에서 보냈는지 특정할 수 있다는 것이 하나의 특징이라 할 수 있겠다.

결론

문서에 나와있는 내용 그대로, 라우팅 모드 시 캡슐화를 사용하는 것도 나름의 장점이 있다.

반면 MTU를 소모하는 단점이 있는 것 역시 확인됐고, 암복호화와 마찬가지로 패킷 처리 작업에 연산 자원이 소모된다는 점은 아쉬운 점이기도 하다.

두 프로토콜 중 어떤 걸 사용하는 것이 좋겠냐고 한다면 기능성을 봤을 때는 geneve가 조금 더 괜찮은 선택지라는 생각은 든다.
애초에 vxlan을 보완하면서 나온 프로토콜이고 확장 가능성이 있는 한편 기본적인 패킷의 크기는 vxlan과 동일하다.
그리고 외부 클라이언트가 서비스로 접근했을 때 vxlan에서는 불가능한 DSR(Direct Server Return, 3자를 거쳐 트래픽을 받은 서버가 클라이언트에게 바로 응답을 주는 기법)이 geneve에선 가능하기도 하다.[5]
geneve의 DSR은 네이티브 라우팅 모드보다 더 안전할 수도 있다.
실리움은 DSR을 쓸 때 IP 헤더에 특정 옵션을 넣는데, 이는 어떤 라우터냐에 따라 해당 패킷을 드랍시키는 경우도 존재한다.
GENEVE의 경우 한 차례 캡슐화를 시키기 때문에 이러한 문제로부터는 자유롭다.

이 부분은 다음 노트에서 로드밸런서를 다루면서 한번 실험해보자.

이전 글, 다음 글

다른 글 보기

이름 index noteType created
1W - 실리움 기본 소개 1 published 2025-07-19
1W - 클러스터 세팅 및 cni 마이그레이션 2 published 2025-07-19
1W - 기본 실리움 탐색 및 통신 확인 3 published 2025-07-19
2W - 허블 기반 모니터링 4 published 2025-07-26
2W - 프로메테우스와 그라파나를 활용한 모니터링 5 published 2025-07-26
3W - 실리움 기본 - IPAM 6 published 2025-08-02
3W - 실리움 기본 - Routing, Masq, IP Frag 7 published 2025-08-02
4W - 실리움 라우팅 모드 실습 - native, vxlan, geneve 8 published 2025-08-09
4W - 실리움 로드밸런서 기능 - 서비스 IP, L2 9 published 2025-08-09

관련 문서

지식 문서, EXPLAIN

이름5is-folder생성 일자
설치 요구사항false2025-07-06 10:34
ebpf 동작 가이드false2025-07-06 10:49
Hubblefalse2025-07-06 10:38
0주차 검증false2025-07-06 12:46
Ciliumfalse2025-06-15 23:42

기타 문서

Z0-연관 knowledge, Z1-트러블슈팅 Z2-디자인,설계, Z3-임시, Z5-프로젝트,아카이브, Z8,9-미분류,미완
이름16코드타입생성 일자
4W - 실리움 로드밸런서 기능 - 서비스 IP, L2Z8published2025-08-09 21:56
1W - 실리움 기본 소개Z8published2025-07-19 22:44
실리움 1주차Z8topic2025-07-13 19:50
실리움 개괄Z8topic2025-07-19 11:00
기본 실리움 탐색 및 통신 확인Z8topic2025-07-19 23:05
클러스터 세팅 및 cni 마이그레이션Z8topic2025-07-19 10:13
실리움 2주차Z8topic2025-07-20 19:05
노드로컬 dnsZ8topic2025-08-02 12:57
실리움 3주차Z8topic2025-07-27 19:44
1W - 클러스터 세팅 및 cni 마이그레이션Z8published2025-07-19 23:38
3W - 실리움 기본 - IPAMZ8published2025-08-02 19:48
1W - 기본 실리움 탐색 및 통신 확인Z8published2025-07-19 23:45
3W - 실리움 기본 - Routing, Masq, IP FragZ8published2025-08-02 22:23
Cilium 공식 문서 핸즈온 스터디Z8published2025-07-05 20:47
2W - 프로메테우스와 그라파나를 활용한 모니터링Z8published2025-07-26 21:15
2W - 허블 기반 모니터링Z8published2025-07-26 21:08

참고

  1. https://datatracker.ietf.org/doc/html/rfc7348 ↩︎

  2. https://aws.amazon.com/ko/blogs/tech/aws-mtu-mss-pmtud/ ↩︎

  3. https://datatracker.ietf.org/doc/html/rfc8926 ↩︎

  4. https://think.unblog.ch/en/maximum-transmission-unit-mtu-check/ ↩︎

  5. https://docs.cilium.io/en/stable/network/kubernetes/kubeproxy-free/#direct-server-return-dsr-with-geneve ↩︎